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(54) Title: NETWORK MANAGEMENT SYSTEM USING MODEL-BASED INTELLIGENCE 



(57) Abstract 

A network management system includes a user interface, a 
virtual network and a device communication manager. The virtu- 
al network includes models which represent network entities and 
model relations which represent relations between network enti- 
ties. Each model includes network data relating to a correspond- 
ing network entity and one or more inference handlers for pro- 
cessing the network data to provide user information. The system 
performs a fauh isolation technique wherein the fault status of a 
network device is suppressed when it is determined that the de- 
vice is not defective. User displays include hierarchical location 
views and lopolo?^ ^al views of the network configuration. Ne- 
twork devices ar;.- .-presented on the displays by multifunction 
icons which perm the user to select additional displays showing 
detailed information regarding different aspects of the corre- 
sponding network device. 
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NETWORK MANAGEMENT SYSTEM USING 
MODEL-BASED INTELLIGENCE 

Field of the Inventiion 

This invention relates to sys^.ems for management 
of computer networks and, more pa . tiicular ly , to 
network management systems which utilize 
interrelated, intelligent models of network entities 
to form a virtual network. 

Backcrround of the Invention '"^^ 

Computer networks are widely used to provide 
increased computing power, sharing of resources and 
communication between users. Computer systems and 
computer system components are interconnected to 
form a network. Networks may include a number of 
computer devices within a room, building or site 
that are interconnected by a high speed local data 
link such as local area network (LAN), token ring, 
Ethernet, or the like. Local networks in different 
locations may be interconnected by techniques such 
as packet switching, microwave links and satellire 
links to form a world-wide network. A network may 
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include several hundred or more interconnected 
devices . 

In computer networks, a number of issues arise, 
including traffic overload on parts of the network, 
optimum placement of network resources, security, 
isolation of network faults, and the like. These 
issues become more complex and difficult as networks 
become larger and more complex. For example, if a 
network device is not sending messages, it may be 
difficult to determine whether the fault is in the 
network device itself, the data commxinicat ion link 
or an intermediate network device between the 
sending and receiving network devices . 

Network management systems have been utilized in 
the past- in attempts to address such issues. Prior 
art network management systems typically operated by 
remote access to amd monitoring of information from 
network devices. The network management system 
collected large volxames of information which 
required evaluation by a network administrator. 
Prior art network management systems place a 
tremendous burden on the network administrator. He 
must be a networking expert in order to understand 
the implications of a change in a network device 
parameter. The administrator must also xinderstand 
the topology of each section of the network in order 
to understand what may have caused the change. In 
addition, the administrator must sift through reams 
of information and false alarms in order to 
determine the cause of a problem. 
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It is therefore desirable to provide ct network 
management system which can sysrematize the 
knowledge of the networking expert such that common 
problems can be detected, isolated and repaired, 
either automatically or with the involvement of less 
skilled personnel. 5 h a system musr have certain 
characteristics in oraer to achieve this goal. The 
system must have a complete and precise 
representation of the nerwork and the networking 
technologies involved. It is insufficient to extend 
prior art network management systems to include 
connections between devices. A network is much more 
than the devices and the wires which connect them. 
The networdk involves the network devices, the 
network protocols and the software running on the 
devices. Without consideration of these aspects of 
the network, a model is incomplete. A system must 
be flexible and extendable. It must allow not only 
for the modeling of new devices, but must allow for 
the modeling of new technologies, media applications 
and protocol. The system must. provide a facility 
for efficiently encapsulating the expert's knowledge 
into the system. 

It is a general object of the present invention 
to provide improved methods and apparatus for 
managing networks. 

It is another object of the present invention to 
provide network management systems which utilize 
models of network entities and interrelationships 
between network entities. 
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It is a further object of the present invention 
to provide network management systems which utilize 
model-based intelligence to represent a physical 
network. 

It is yet another object of the present 
invention to provide network management systems 
wherein models of network entities encapsulate data 
and intelligence relating to the network entity. 

Summary of the Invention 

According to the present invention, these and 
other objects and advantages are achieved in a 
method and apparatus for managing networks. A 
system for use with a computer network comprises a . 
virtual network including a plurality of models for 
representing network entities, each model containing 
network data relating to a corresponding network 
entity and means for processing the network data to 
provide user information. The virtual network 
further includes model relations representing 
relations between the network entities. The system 
also includes means for transferring network data 
from the network entities to the corresponding 
models in the virtual network and means for 
supplying the user information from the virtual 
network to a user. 

The system of the present invention employs 
model-based intelligence to create- a representation 
of an entire network. The models represent network 
devices, geographical locations of network devices. 
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topological groupings of network devices, software 
applications being executed on the network devices 
or any other network entity for which a management 
function is to be performed. The model relations 
define both network connections between network 
devices and hierarchical relationships between 
network entities. 

The virtual network includes means for polling 
selected network devices and updati':'g the network 
data in the corresponding models. Tne polling is 
performed at intervals which can be different f_r ^ 
different network devices. 

The models are implemented as software objects ^ 
containing both data relating to the corresponding 
network entity and one or more inference handlers 
for processing the data. The inference handlers are 
triggered by predetermined virtual network events 
such as a change in specified network data in the 
same model, a change in specified network data in a 
different model, predefined events cr changes in 
models or model relations. Information pertaining 
to the condition of a network entity can be obtained 
from the network entity by polling or can be 
inferred from data contained in other models . An 
alarm condition is generated when the network data 
meets a predetermined criteria. Events, alarms and 
-"•atistical information from the virtual network are 
£.:.ored in a database and are selectively displayed 
for the user . 
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Brief Description of the Dravings 

For a better understanding of the present 
invention, together with other and further objects, 
advantages and capabilities thereof, reference is 
made to the accompanying drawings which are 
incorporated herein by reference and in which: 

FIG. 1 is a block diagram of a network 
management system in accordance with the invention; 

FIG. 2 is a block diagram showing an example of 
a network; 

FIG. 3 is a schematic diagram showing the 
structure of models and the relations between modiels; 

FIG. 4 is a block diagram showing a portion of 
the representation of the network of FIG. 2 in the 
virtual network machine; 

FIG. 5 is a flow chart illustrating an example 
of operation of the virtual network machine; 

FIG. 6 is a flow chart of a fault isolation 
techniqiie in accordance with the present invention; 

FIGS. 7A-7C show examples of location display 
views provided by the network management system; 

FIGS. 8A and 8B show examples of toplogical 
display views provided by the network management 
system; 

FIG. 9 is a schematic diagram of a multifunction 
icon employed in the user display views; and 

FIG. 10 shows an example of an alarm log display 
provided by the network management- system. 
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Detailed Description of the Invention 

A block diagram of a network management system 
in accordance with the present invention is shown in 
FIG. 1. The major components of the network 
management system are a user interface 10, a virtual 
network machine 12, and a device communication 
manager 14. The user interface 10, which may 
include a video display screen, keyboard, mouse and 
printer, provides all interaction with the user. 
The user interface controls the screen, keyboard, 
mouse and printer and provides the user with 
different views of the network that is being 
managed. The user interface receives network 
information from the virtual network machine 12. . 
The virtual network machine 12 contains a software 
representation of the network being managed, 
including models that represent the devices and 
other entities associated with the network, and 
relations between the models. The virtual network 
machine 12 is associated with a database manager 16 
which manages the storage and retrieval of 
disk-based data. Such data includes configuration 
data, an event log, statistics, history an current 
state information. The device communication manager 
14 is connected to a network 18 and handles 
communication between the virtual network machine 12 
and network devices. The data received from the 
ner- k devices is proviied by the device 
CO" . . .ication manager to the virtual network machine 
12. The device communication manager 14 converts 



generic requests from the virtual network machine 12 
to the required network management protocol for 
communicating with each network device. Existing 
network management protocols include Simple Network 
Management Protocol (SNMP) , Internet Control Message 
Protocol (ICMP).and many proprietary network 
management protocols. Certain types of network 
devices are designed to communicate with a network 
management system using one of these protocols. 

A view personality module 20 connected to the 
user interface 10 contains a collection of data 
modules which permit the user interface to provide 
different views of the network. A device 
personality module 22 connected to the virtual 
network machine 12 contains a collection of data 
modules which permit devices and other network 
entities to be configured and managed with the 
network management system. A protocol personality 
module 24 connected to the device communication 
manager contains a collection of data modules which 
permit communication with all devices that 
communicate using the network management protocols 
specified by the module 24. The personality modules 
20, 22 and 24 provide a system that is highly 
flexible and user configurable. By altering the 
personality module 20, the user can specify 
customized views or displays. By changing the 
device personality module 22, the user can add new 
types of network devices to the system. Similarly, 
by changing the protocol personality module 24, the 



BNSDOCID: <WO 9205485A2_I_> 



wo 92/05485 



PCr/US91/06725 



- 9 - 



network management system can operate with new or 
different: network management protocols. The 
personality modules permit the system to be 
reconfigured and customized without changing the 
basic control code of the system. 

The overall software architecture of the present 
invention is shown in FIG. 1. The hardware for 
supporting the system of FIG. l is typically a 
workstation such as a Sun Model 3 or 4 , or a 386 PC 
compatible computer running Unix. A minimum of 8 
megabytes of memory is required with a display 
device which supports a minimvim of 640 x 680 pixels 
X 256 color resolution. The basic software includes 
a Unix release that supports sockets, X-windows and 
Open Software Foundation Motif 1.0. The network 
management system of the present invention is 
implemented using the C++ programming language / but 
could be implemented in other object-oriented 
languages such as Eiffel, Smalltalk, ADA, or the 
like. The virtual network machine 12 and the device 
communication manager 14 may be run on a separate 
computer from the user interface 10 for increased 
operating speed. 

An example of a network is shown in FIG. 2. The 
network includes workstations 30, 31, 32, 33 and 
disk units 34 and 35 interconnected by a data bus 
36. Workstations 30 and 31 and disk unit 34 are 
located in a room 38, and workstations 32 and 33 and 
disk unit 35 are located in a room 40. The rooms 38 
and 40 are located within a building 42. Network 
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devices 44, 45 and 46 are interconnected by a data 
bus 47 and are located in a building 48 at the same 
site as building 42. The network portions in 
buildings 42 and 48 are interconnected by a bridge 
50. A building 52 remotely located ( in a different 
city, state or covmtry) from buildings 42 and 48, 
contains network devices 53/ 54, 55 and 56 
interconnected by a data bus 57. The network 
devices in building 52 are interconnected to the 
network in building 48 by interface devices 59 and 
60, which may communicate by a packet switching 
system, a microwave link or a satellite link. The 
network management system shown in FIG.l and 
described above is connected to the network of FIG. 
2 at any convenient point, such as data bus 36. 

In general, the network management system shown 
in FIG. 1 performs two major operations during 
normal operation. It services user requests entered 
by the user at user interface 10 and provides 
network information such as alarms and events to 
user interface 10. In addition, the virtual network 
machine 12 polls the network to obtain information 
for updating the network models as described 
hereinafter. In some cases, the network devices 
send status information to the network management 
system automatically without polling. In either 
case, the information received from the network is 
processed so that the operational status, faults and 
other information pertaining to the network are 
presented to the user in a systematized and 
organized manner . 
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As indicated above, the network entities that 
make up the network that is being managed by the 
network management system are represented by 
software models in the virtual network machine 12. 
The models represent network devices such as printed 
circuit boards, printed circuit board racks, 
bridges, routers, hubs, cables and the like. The 
models also represent locations or topologies. 
Location models represent the parts of a network 
geographically associated with a building, country, 
floor, panel, rack, region, room, section, sector,^ 
site or the world. Topological models represent the 
network devices that are topologically associated 
with a local area network or subnetwork. Models can 
also represent components of network devices such as 
individual printed circuit boards, ports and the 
like. In addition, models can represent software 
applications such as data relay, network monitor, 
terminal server and end point operations. In 
general, models can represent any network entity > 
that is of interest in connection with managing or 
monitoring the network. 

The virtual network machine includes a 
collection of models which represent the various 
network entities. The models themselves are 
collections of C++ objects. The virtual network 
machine also includes model relations which define 
the interrelationships between the. various models. 
Several types of relations can be specified. A 
"connects to" relation is used to specify an 
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interconnection between network devices. For 
example, the interconnection between two 
workstations is specified by a "connects to" 
relation. A "contains" relation is used to specify 
a network entity that is contained within another 
network entity. Thus for example, a workstation 
model may be contained in a room, building or local 
network model. An "executes'* relation is used to 
specify the relation between a software application 
and the network device on which it r\ins . An "is 
part of" relation specifies the relation between a 
network device and its components. For example, a 
port model may be part of a board model or a card 
rack model . 

Relations are specified as pairs of 
associations. The relations can specify 
peer-to-peer associations and hierarchical 
associations . 

Each model includes a number a attributes and 
one or more inference handlers. The attributes are 
data which define the characteristics and status of 
the network entity being modeled. Basic attributes 
include a model name, a model type name, a model 
type handle, a polling interval, a 

next-time-to-poll, a retry count, a contact status, 
an activation status, a time-of-last-poll and 
statistics pertaining to the network entity which is 
being modeled. Polling of network- devices will be 
described hereinafter. In addition, attributes that 
are unique to a particular type of network device 
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can be defined. For example, a network bridge 
contains a table that defines the devices that are 
located on each side of the bridge. A model of the 
network bridge can contain, as one of its 
attributes, a copy of the table. 

In a preferred embodiment of the invention, each 
attribute contained in a model type includes the 
following : 

1. An attribute name that identifies the 
attribute. 

2. An attribute type that defines the kind 
of attribute. At* bute types may include 
Boolean values, integers, counters, dates, text 
strings, and the like. 

3. Attribute flags indicate how the 
attri-:ute is to be manipulated. A memory flag 
indicates that the attribute is stored in 
memory. A database flag indicates that the 
attribute is maintained in the database of the 
virtual network machine. An external flag 
indicates that the attribute is maintained in 
the device being modeled. A polled flag 
indicates that the attributes' value should be 
periodically surveyed or polled by the device 
being modeled. The flags also indicate whether 
the attribute is readable or writable by the 
user . 

4. Object identifier is the identifier 
used to access the attribute in the device. It 
is defined by the network management protocol 
used to access the device. 
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5. Attribute help string is a text string 
which contains a description of the defined 
attribute. When the user asks for help 
regarding this attribute, the text string 
appears on the user interface screen. 

6. Attribute value is the value of the 
attribute. 

The models used in the virtual network machine 
also include one or more inference handlers. An 
inference handler is a C+-i- object which performs a 
specified computation, decision, action or 
inference. The inference handlers collectively 
constitute the intelligence of the model. An 
individual inference handler is defined by the type 
of processing performed, the source or sources of 
the stimulus and the destination of the result. The 
result is an output of an inference handler and may 
include attribute changes, creation or destruction 
of models, alarms or any other valid output. The 
operation of the inference handler is initiated by a 
trigger, which is an event occurring in the virtual 
network machine. Triggers include attribute changes 
in the same model, attribute changes in another 
model, relation changes, events, model creation or 
destruction, and the like. Thus, each model 
includes inference handlers which perform specified 
f\inctions upon the occurrence of predetermined 
events which trigger the inference handlers. 
A schematic diagram of a simple model 
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configuration is shown in FIG. 3 to illustrate the 
concepts of the present invention. A device model - 
8 0 includes attributes 1 to x and inference 
handlers 1 to 3;. A device model 82 includes 
attributes 1 to u and inference handlers 1 to 
V. A connect relation 84 indicates that models 80 
and 82 are connected in the physical network. A 
room model 86 includes attributes 1 to m and 
inference handlers 1 to n. A relation 88 
indicates that model 80 is contained within room 
model 86, and a relation 90 indicates that model 82 
is contained within room model 86. Each of the 
models and the model relations shown in FIG. 3 is 
implemented as a C-H- object. It will be understood 
that a representation of an actual network would be 
much more complex than the configuration shown in 
FIG. 3. 

As discussed above, the collection of models and 
model relations in the virtual network machine form 
a representation of the physical network being 
managed. The models represent not only the 
configuration of the network, but also represent its 
status on a dynamic basis. The status of the 
network and other information and data relating to 
the network is obtained by the models in a number of 
different ways. A primary technique for obtaining 
information from the network involves polli-^.g. At 
specified intervals, a model in the virtual network 
machine 12 requests the device communication manager 
14 to poll the network device which corresponds to 
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the model. The device communication manager 14 
converts the request to the necessary protocol for 
communicating with the network device. The network 
device returns the requested information to the 
device communication manager 14, which extracts the 
device information and forwards it to the virtual 
network machine 12 for updating one or more 
attributes in the model of the network device. The 
polling interval is specified individually for each 
model and corresponding network device, depending on 
the importance of the attribute, the frequency with 
which it is likely to change, and the like. The 
polling interval, in general, is a compromise 
between a desire that the models accurately reflect 
the present status of the network device and a 
desire to minimize network management traffic which 
could adversely impact normal network operation. 

According to another technique for updating the 
information contained in the models, the network 
devices automatically transmit information to the 
network management system upon the occurrence of 
significant events without polling. This requires 
that the network devices be preprogrammed for such 
operation. 

It will be xinder stood that communication between 
a model and its corresponding network entity is 
possible only for certain types of devices such as 
bridges, card racks, hubs, etc. In other cases, the 
network entity being modeled is not capable of 
communicating its status to the network management 
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system. For example, models of buildings or rooms 
containing network devices and models of cables 
cannot communicate with the corresponding network 
entities. In this case, the status of the network 
entity is inferred by the model from information 
contained in models of other network devices. Since 
successful polling of a network device connected to 
a cable may indicate that the cable is functioning 
properly, the status of the cable can be inferred 
from information contained in a model of the 
attached network device. Similarly, the operational 
status of a room can be inferred from the 
operational status contained in models of the 
network devices located within the room. In order . 
for a model to make such inferences, it is necessary 
for the model to obtain information from related 
models. In a function called a model watch, an 
attribute in one model is monitored or watched by 
one or more other models. A change in the watched 
attribute may trigger inference handlers in the 
watching models. 

The virtual network machine also includes an 
event log, a statistics log and an alarm log. These 
logs permit information contained in the models to 
be organized and presented to the user and to be 
recorded in the database. 

The event message provides specific information 
about events, including alarms that have occurred in 
a given model. The events pass from the model to an 
event log manager which records the event in the 
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external database. An event message is also sent to 
the user interface based on event filters, as 
discussed below. The user can request event 
information from the database. An event message 
includes a model handle, a model-type handle, an 
event date and time, an event type and subtype, an 
event severity, a model name, a model-type name, an 
event user name, an event data count and event 
variable data. The event variable data permits 
additional information to be provided about the 
event . 

Event messages sent to the user interface can 
utilize a filter process that is specified by the 
user. The user can specify model types and a 
minimum event severity for which events will be 
displayed on the user screen. Events from 
unspecified model types or less than the minimum 
severity will not be displayed. Many other event 
selection or filtering criteria can be used. In 
general, any information contained in the event 
message can be used for event filtering. 

Statistics history messages are similar to the 
event messages described above. The statistics 
information includes any model parameters or 
functions which the user wishes to monitor. A 
statistics history message passes from the model to 
a statistics log manager and subsequently to the 
external database. The statistics .message is also 
sent to the user interface based predefined filter 
parameters- The user can request the statistics log 
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manager to obtain and display statistics information 
from the external database. Statistics messages are 
compiled whenever a device read procedure occurs. 

When an alarm event occurs in a model, a notice 
of the alarm event is sent to an alarm log and to 
the event log. The alarm log selects the most 
severe alarm for each model which is registering an 
alarm. The alarms are sent to an alarm window in 
the user interface. The user can obtain more 
information on the alarm message by pressing an 
appropriate button on the window display. Alarm log 
messages include the following parameters: alarm 
condition, alarm cause, alarm status, alarm security 
data, alarm clear switch and alarm unique ID. 

An example will now be given to illustrate 
operation of the virtual network machine 12. A 
portion of the virtual machine 12 is shown 
schematically in FIG. 4. The models shown in FIG. 4 
correspond to network entities shown in FIG. 2. A. - 
flow chart illustrating the example is shown in FIG; 
5. Each network device has a model in the virtual 
network machine 12. Thus, for example, model 144 
corresponds to network device 44, model 145 
corresponds to network device 45, etc. Models 144 
and 145 are related by connection relation 147 which 
corresponds to data bus 47. Room model 148 is 
related to models 144 and 145 by a contains relation. 

In operation, at a specified time model 144 
initiates polling of network device 44 in step 200 
in-order to obtain an update of the status of 
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network device 44. The model 144 sends a request to 
the device coiranunication manager 14 to poll network 
device 44 . The device communication manager 14 
converts the request to the required protocol for 
communication with network device 44 and sends the 
message. The requested information may, for 
example, be the nximber of packets sent on the 
network in a given time and the number of errors 
that occurred. When the requested information is 
returned to model 144, the corresponding attributes 
in model 144 are updated in step 206 and an error 
rate inference handler is triggered. The error rate 
inference handler in step 208 calculates the error 
rate for network device 44. If the error rate is 
within prescribed limits (step 210), an error rate 
attribute is updated, and the new information is 
logged into the database (step 212). If the 
calculated error rate is above a predetermined 
limit, an error alarm inference handler is 
triggered. The error alarm inference handler may 
shut off the corresponding network device 44 and 
send an alarm to the user interface in step 214. 
The alarm is also logged in the database. If the 
network device 44 is shut off in response to a high 
error rate, a condition attribute in model 144 is 
updated to reflect the off condition in step 216. 
If no response was received from the network device 
44 when it was polled (step 218), a fault isolation 
inference handler is triggered in step 220. The 
fault isolation inference handler operates as 
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described below tb determine the network component 
which caused network device 44 to fail to respond to 
the poll. When the cause of the fault is 
determined, a fault message is sent to the user 
interface. 

Polling of network device 44 is repeated at 
intervals specified by an attribute contained in 
model 144. In adcition, other network devices are 
polled at intervals which may be different for each 
network device. The information returned to each 
model is processed by the inference handlers for 
that model and by inference handlers in other models 
that are watching such information. In general, 
each model type may include a different set of 
inference handlers. 

As described above, an attribute change in one 
model can trigger an inference handler in one or 
more other models and thereby produce a chain of 
actions or responses to the attribute change. For 
example, if a fault occurs in a network device, the 
condition attribute of that device is changed in the 
.corresponding model. The condition change may 
trigger a condition change in the model of the room 
which contains the device. Likewise, the condition 
change in the room may trigger a condition change in 
the building or site model. The condition attribute 
in each model may have a different level of 
significance. For example, failure of a device may 
have a high significance in the network device model 
but a relatively low significance in the site 
model . 
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The software models and model relations that are 
representative of a network as described herein are 
highly flexible and adaptable to new network 
configurations and new management functions. New 
models and model relations are easily added to the 
virtual network machine to accommodate the needs of 
the user. The use of the C+-i- programming language 
permits new model types to be derived from existing 
model types. Thus, the virtual network machine 12 
can be customized for a particular application. 

A model type editor is used to modify and 
control the models in the virtual network machine 
1*2. The following functions are provided: 

1. Describe () describes some aspect of • 
the specified model type. 

2. Create () creates a new model for the 
specified model type. 

3. Destroy () removes the specified model 
from the configuration. 

4 . Read ( ) reads the value of the 
specified attribute from a model. 

5. Write () writes the given values to the 
attributes of the model . 

6. Action () performs the specified action. 

7 . Generate event ( ) creates an event 
message. 

Similarly, the model relations can be edited by 
the user. The following functions- can be performed 
on model relations. 

1. Describe () describes an aspect of the 
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specified relation, 

2. Read {) reads a set of associations. 

3. Add () adds an association. 

4. Remove () removes a set of associations. 

5 . Count ( ) returns the niimber of 
associations that match the selection 
criteria. 

6. Read rule () reads a set of relation 
rules . 

As indicated above, each inference handler is 
triggered by the occurrence of a specified event or 
events. The user must register the inference 
handler to receive the trigger. An inference 
handler can be triggered upon the creation or 
destruction of a model, the activation or 
initializing of a model, the change of an attribute 
in the same model, the change of an attribute in a 
watched model, the addition or removal of a 
relation, the occurrence of a specified event or a 
user-defined action. 

The virtual network machine described above 
including models and model relations provides a very 
general approach to n<=>twork management . By 
customizing the virtual network machine, vir :ually 
any network management function can be implemented. 
Both data (attributes) and intelligence (inference 
handlers) are encapsulated into a model of a network 
entity. New models can be generated by combining or 
modifying existing models since the models are 
implemented in the C++ programming language. A 
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model can be identified by a variety of cifferent 
dimensions or names, depending on the attributes 
specified. For example, a particular network device 
can be identified as a device, a type of device, or 
by vendor or model nxomber . Models are interrelated 
with each other by different types of relations. 
The relations permit stimulus-response chaining. 
The model approach provides loosely-coupled 
intelligent models with interaction between models 
according to specified triggers. The system has 
data location independence. The data for operation 
of the virtual network machine may reside in the 
database, memory or in the physical network which is 
being modeled. 

An important function of a network management 
system is the identification and isolation of 
faults. When the network management system loses 
contact with a network device, the reason for the 
loss of contact must be determined so that 
appropriate action, such as a service call, can be 
taken. In a network environment, loss of contact 
with a network device may be due to failure of that 
network device or to failure of another network 
device that is involved in transmission of the 
message. For example, with reference to FIG. 2, 
assume that contact is lost with network device 53 . 
The loss of contact could be due to the failure of 
network device 53, but could also be due to the 
failure of network devices 50, 60 or 59. In prior 
art network management systems, the network 



BNSDOCID: <WO 9205485A2_I_> 



wo 92/05485 



PCr/US9 1/06725 



- 25 - 



administrator was typically providad with a list of 
possible causes of a fault and was required to 
isolate the fault based on his experience and 
knowledge of the network. 

In accordance with a feature of the present 
invention, the network management system isolates 
network faults using a technigiie known as status 
suppression. When contact between a model and its 
corresponding network device is lost, the model sets 
a fault status and initiates the fault isolation 
technique. Accoru .ng to the fault isolation 
technique, the model (first model) which lost 
contact with its corresponding network device {first 
network device) determines whether adjacent models 
have lost contact with their corresponding network 
devices. In this context, adjacent network devices 
are defined as those which are directly connected to 
a specified network device. If adjacent models 
cannot contact the corresponding network devices, 
then the first network device cannot be the cause of 
the fault, and its fault status in the first model 
is suppressed or overridden. By suppressing the 
fault status of the network devices which are 
determined not to be defective, the defective 
network device can be identified. 

The fault isolation technique .is advantageously 
implemented in the conjunction with the model-based 
representation of the network and polling of netwcrk 
devices as described above. In a preferre.. 
embodiment of the fault isolation technique, each 
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model that is capable of polling its correspondi)xg 
network device maintains a fault status for that 
device. If contact with the device is lost/ the 
fault status is set. Each such model also maintains 
a count of the niimber of network devices that are 
directly connected to the network device. In 
addition, each such model maintains a co\int of the 
number of adjacent network devices for which contact 
has been lost. This information is determined by 
each model watching the fault status in models 
corresponding to adjacent network devices. When a 
given model loses contact with is corresponding 
network device, two operations are performed. The 
fault status of the model is set, and the count of 
total adjacent devices is compared with the count of 
adjacent devices for which the fault status is set. 
If the counts are equal, all adjacent models have 
lost contact with their corresponding network 
devices. In this case, the fault status of the 
first model is suppressed. 

Since models that are capable of polling network 
devices perform polling regularly on an asynchronous 
basis, the fault status of each such model is 
regularly updated. However, when the fault 
isolation techniqiie described above is used, the 
fault status is suppressed in those models which are 
determined not to be defective. Thus, the fault 
status contained in the models is an accurate 
representation of defective network devices. 

A flow chart of the fault isolation technique is 
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shown in Fig. 6. When a model D loses contact with 
the corresponding network device D (step 250), model 
D sets its fault status in step 252. Model D then 
obtains the fault status of all devices which are 
adjacent to device D in step 252. The fault status 
of adjacent devices is determined from the fault 
status maintained in models of adjacent devices. In 
step 256 the number of adjacent devices 
adjacent to device D is compared with the number of 
ad. ^cent devices having a fault Np. if is 
not equal to Np, contact can be made with at least 
one device adjacent to device D, and the fault 
status of device D is maintained. If N,j^ = Np, 
contact has been lost with all devices adjacent to . 
device D and the fault status of device D is 
suppressed in step 258. As described above, this 
procedure is performed each time a model loses 
contact with its corresponding network device. _ 
By way of example, assume that model 144 (Fig. 
4) is unable to contact its corresponding network 
device 44 (Fig. 2). The model 144 sets its fault 
status and obtains the fault status of adjacent 
devices 45, 46, 60 and 50 from the corresponding 
models. Assume in this case that the cause of the 
fault is the bridge device 50. Since the adjacent 
devices 45, 46, 60 and 50 cannot be contacted by the 
corresponding models, the fault status of these 
devices will be set in the corresponding models. 
Model 144 will therefore determine that the fault 
status of all adjacent devices is set and will 
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suppress its own fault status. In this example, the 
topological configuration of the network and the 
corresponding models are used to isolate the source 
of a fault and to suppress the fault status of 
downstream network devices . 

The fault isolation technique described above 
can also be applied in a geographical 
configuration. For example, assume that contact is 
lost with network devices 30, 31 and 34 in room 38 
as shown in FIG. 2, In this case, it is likely that 
all devices within the room have failed due to a 
power loss or a failure of data bus 36. In this 
case, the fault status of devices 30, 31 and 34 is 
suppressed in corresponding models 130, 131 and 134, 
and the fault status of room 42 is maintained. 

The above examples relate to hardware faults. 
The fault isolation technique of the invention can 
also be applied to isolation of software faults. As 
indicated above, the virtual network machine may 
include models of application software running on 
the network devices. Assume, for example, that 
contact is lost with an electronic mail application 
running on a specified network device. The 
electronic mail application may depend on other 
software, such as a file transfer module, for its 
operation. The electronic mail application may have 
failed to respond because of a failure of the file 
transfer module. The technique described above can 
be utilized to isolate the software application 
having a fault. 
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The fault isolation technique described above is 
particularly useful in a network management system 
utilizing model-based intelligence as described 
above. However, the fault isolation technique is 
not limited to such use. The fault isolation 
technique of determining the fault status of 
adjacent devices and suppressing the fault status of 
the first device when the fault status of all 
adjacent devices is set, can be applied in a network 
management system that does not use models of 
network entities. Furthermore, the fault isolation 
technique is not limited to network management 
systems. The technique is more generally applicable 
to any system where it is. desired to determine and 
isolate the cause of a problem or fault by . 
suppressing symptomatic information. 

As indicated above, the user interface 10 
provides information concerning the network to a 
user. The primary device for presenting network , 
information to the user is a video display screen, 
The display screen utilizes a high resolution, 
window-based display system to provide different 
views or displays of the network configuration and 
operation. The user display is based on the 
X-Window system which includes routines for 
generating the appropriate display, or view based on 
input data. The X-Window system is a standard 
window controller developed by the .X-Consortium at 
Massachusetts Institute of Technology. The display 
screen is used in conjunction with a mouse to permit 
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the user to select different views of the network. 
It will be understood that the user interface can be 
implemented using other window-based systems. 

The network management system provides multiple 
views, including location views, topological views 
and generic views, of the network. Multifunction 
icons are used in some views to represent different 
network entities. The location and topological 
views are organized in a hierarchical manner. By - 
clicking on specified elements of a view, the user 
can obtain a view of the next lower level in the 
hierarchy. As used herein, '^clicking" refers to 
using the mouse to move the cursor to a specified 
location on the display screen and then depressing 
the mouse button. 

In the location views, the highest level may 
show a map of the world with network locations 
indicated thereon. Intermediate views may show a 
map of a co\intry or a region, while lower level 
views may show the floor plan of a building or room 
that contains network devices. ^ At the lowest level, 
the user may obtain a pictorial view of an 
individual device. 

Examples of location views are shown in Figs. 
7A-7C, A map 300 of the northeast region, with 
network locations indicated by icons 3 02, is shown 
in FIG. 7A. The icons 302 each include a name label 
304 pointing to a circle 306 which indicates a 
network location. The color of the circle 306 
indicates a status of that location. For example. 
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green m-y indicate a normal status, whereas red may 
indicate a fault or croxible status. By clicking on 
one of the network locations, the next lower level 
location view can be obtained. In this example, a 
floor plan 310 of the headquarters network is shown 
in FIG. 7B. Locations of network devices are 
indicated by icons 312 which are similar to ions 302 
described above. By clicking on one of the icons 
312 shown in FIG. 7B, a location view of a single 
room 318 is displayed as shown in FIG. 7C . In this 
case, the network devices contained within a 
computer lab are represented by multifunction icons 
320, 322, which will be described in detail 
hereinafter . 

In the topological views, a similar hierarchy is 
utilized, and the connections between network 
elements are shown. At the highest level, network 
interconnections at a worldwide or national level 
are shown. At each lower level, more detailed 
views, such as local area networks and subnetworks, 
are shown. 

Examples of topological views are shown in FIGS. 
8A and 8B. In FIG. 8A, a topological view of a 
corporate site is shown. An administration network 
icon 33 0 and an engineering net:work icon 332 are 
interconnected to an Internet icon 334 by links 
336. Each network is represented by a multifunction 
icon. By clicking on the engineering network ic 
332, a view of the details of the engineering 
network is obtained, as shown in FIG. SB. The 
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network devices in the engineering network are 
represented by multifunction icons 340, 342, 344, 
and the interconnections 346 between network devices 
are shown. 

The location and topological views represent 
different dimensions of the same network. The user 
can traverse between location and topological views 
to obtain any necessary information regarding the 
configuration of the network. The user display also 
provides generic views such as an alarm log, an 
event log, a text display, a chart, or any other way 
of displaying attribute information. The user 
traverses between available views to obtain required 
network information. There are two basic ways of 
traversing between views. As indicated above, the 
user can click on icons in the location and 
topological views to traverse to the next lower 
level in the hierarchy of views. Also, the 
different views include pull-down menus, as commonly 
used in window-based displays, which permit 
selection of any desired view. 

Each view that is available to the user has a 
corresponding view manager in the user interface. 
Similarly, each icon has a corresponding icon 
manager in the user interface. The view manager 
serves as the common parent for all parent icon 
managers associated with a given view. The view 
manager saves icon screen placement information and 
the associated virtual network machine model handles 
that the icons represent. The view manage'^r 
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determines other views to which a user may traverse 
from the current view. The view manager displays 
appropriate menu items and allows the user to select 
other views . The view manager may permit the user 
to traverse from a location view to a topological 
view, or vice versa. 

The icon manager class is an instantiated C+H- 
class with one or more icon managers controlling 
each icon. Each icon manager controls some part of 
the on- .creen display, such as a bar graph, an arrow 
or the entire backgroiind of an icon. The icon 
manager represents a model within the virtual 
network machine and contains a representation of the 
virtual network machine model at the current time. 
The icon manager can communicate with the virtual, 
network machine model that it represents. When 
attribute data within the virtual network machine 
model changes, the appropriate icon manager is 
notified of the change and modifies the icon 
appearance to reflect the new state, the new 
statistics or appropriate error conditions. Thus, 
the icon manager displays data from the virtual 
machine model which it represents . 

Icon managers are structured in a hierarchical 
manner. A parent icon manager may control a 
background picture of an icon, and the parent 
typically has a group of children icon managers 
attacaed it. Each icon manager has associated with 
it the model handle of the virtual network machine 
model which it represents . 
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The icon manager can place a watch on the 
virtual network machine model that it represents. 
The watch informs the model that an icon manager now 
i:epresents that model within the user interface. 
Any changes in the state of the model are forwarded 
to the corresponding icon manager. The watch 
includes a parameter that specifies the severity 
level of the watch. A change in model attribute 
data must be equal to or greater than the severity 
level set within the model before the icon manager 
receives notification of a change in attribute 
data. Another way to place a watch on a virtual 
network machine model is for the icon manager to set 
a timer to poll the model periodically. A watch is 
generic in that the data received from a watch 
includes a selected set of attribute data for the 
corresponding model. The data in a model may have 
changed extensively since the icon manager was last 
notified. When the icon manager polls a model, it 
reads attribute data from the model and performs 
rec[uired actions. 

When the user clicks on an icon to proceed to 
another view, the icon manager determines the view 
class and the next view. The icon manager then 
issues a new view by passing the view class and the 
appropriate virtual network machine model ID to the 
view executive, thereby causing the current view to 
be destroyed. 

The user interface 10 and the virtual network 
machine 12 communicate via Unix sockets. Messages 
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between these two components are encoded in a 
machine independent format. A user interface object 
such as an icon manager or a view manager may 
communicate with a model, model type or model 
relation in the virtual network machine in order to 
retrieve attribute data. 

The multifunction icons used in the network 
management system provide a highly flexible 
technique for presenting information to the user. 
As shown in FIG. 9, a multifunction icon 400 can 
include an area 402 for a device name, an area 404^ 
for model type information, bar graphs 406 and 408 
for indicating performance parameters such as number 
of packets and error rate, an area 410 for 
displaying an iconic or symbolic representation 412 
of the device, a background area 414 for 
representing the status of the network device by 
different colors and a figure 416 that is used for 
traversing to a pictorial representation of the 
device. Some or all of the areas of the icon can be 
clicked upon to obtain additional information 
regarding the network device. 

In a preferred embodiment, a view showing 
general configuration information relating to the 
network device is provided when the user clicks on 
area 402 or 404 of icon 400. A view showing status 
information pertaining to the device is provided 
when the user clicks on area 410, and a view showing 
performance information is provided when the user 
clicks on bar graphs 406 and 408. As indicated 
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above, a pictorial representation of the network 
device is provided when the user clicks on figure 
416. It will be understood that the multifunction 
icon can include different information and areas, 
depending on the device .being represented and the 
information that is required, and that different 
information and display views can be provided by 
clicking on different areas of the icon. 

The multifunction icons shown and described 
herein are used in an alarm log view that is shown 
in FIG. 10. The alarm log view includes an area 420 
for listing of current alarms, an area 422 for 
display of information pertaining to a selected 
alarm and a button panel 432 which displays options 
available for an alarm. The user may click on a 
particular alarm in the listing of current alarms to 
obtain more information. A multifunction icon 424 
representing the network device having a fault is 
displayed in area 422 with one or more text fields 
426 and 428 which provide information to the user 
regarding the cause of the alarm and the status of 
the device. By clicking on specified areas of the 
icon 424, the user can obtain further information 
regarding the device for which an alarm is 
registered, as described above in connection with 
icon 400. The user can also traverse to the 
location or topological view from the alarm log 
view. By clicking on other alarms- in the alarm 
list, similar information is obtained regarding 
other alarm conditions. 
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The user interface of the network management 
system is highly flexible and permits new views of 
the network to be added to the network management 
system. New views require new view managers and 
icon managers to be instantiated. Since the views 
are implemented as objects, new views and icons 

are easily derived from existing views and icons. 
New views and modifications of existing views are 
easily provided by additions or changes to 
parameters and data which control the views, without 
changes to the control code. 

While there have been shown and described what 
are at present considered the preferred embodiments 
of the present invention, it will be obvious to 
those skilled in the art that various changes and 
modifications may be made therein without departing 
from the scope of the invention as defined by the 
appended claims. 
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CLAIMS 

What is claimed is: 

1. A system for use with a computer network, 
comprising: 

a virtual network including a plurality of 
models for representing network entities, each model 
containing network data relating to a corresponding 
network entity and means for processing said network 
data to provide user information, said virtual 
network further including model relations 
representing relations between said network entities; 

means for transferring network data from said 
network entities to the corresponding models in said 
virtual network; and 

means for supplying said user information from 
said virtual network to a user . 

2. A system as defined in claim 1 wherein said 
virtual network includes means for updating network 
data in said models with new network data received 
from the corresponding network entities. 

3. A system as defined in claim 1 wherein selected 
models in said virtual network include means for 
polling the corresponding network .entity to obtain 
new network data. 
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4. A sysrem as defined in claim 1 wherein said 
model relations represent network connections 
between network devices . 

5. A system as defined in claim 1 wherein said 
model relations represent hierarchical relations 
between said network entities. 

5. A system as defined in claim 1 wherein said 
models represent network devices. 

7. A system as defined in claim 1 wherein said 
models represent the geographical location of 
network entities. 

8. A system as defined in claim 1 wherein said 
models represent a topological grouping of network 
entities. 

9. A system as defined in claim 1 wherein said 
models represent software applications being 
executed on network devices . 

10. A system as defined in claim 1 wherein said 
means for processing is triggered by a change in 
specified network data in the same, model. 

11. A system as defined in claim 1. wherein said 
means for processing is triggered by a change in 
specified network data in a different model. 
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12. A system as defined in claim 1 wherein said 
means for processing includes means for generating 
an alarm condition when said network data satisfies 
a predetermined criteria. 

13. A system as defined in claim 1 wherein said 
means for processing includes means for generating 
an event when said network data satisfies a 
predetermined criteria. 

14. A system as defined in claim 1 wherein said 
means for processing includes a plurality of 
inference handlers each for performing a 
predetermined fxinction. 

15. A system as defined in claim 1 wherein said 
virtual network comprises a programmed digital 
computer . 

16. A method for obtaining user information relating 
to a computer network, comprising the steps of: 

representing network entities of said computer 
network by models, each containing data relating to 
a corresponding network entity; 

representing relations between said network 
entities by model relations; 

updating the data in said models with new data 
from the corresponding network entities; 

processing the data in said models to provide 
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user information; and 

supplying the user information to a user. 

17. A method as defined in claim 16 wherein the step 
of updating the data in said models includes polling 
by selected models of the corresponding network 
entities at predetermined times to obtain new data. 

18. A method as defined in claim 16 wherein the step 
of updating the data in said models includes the 
step of receiving new data automatically sent by 
said network entities and updating the data in 
corresponding models. 

19. A method as defined in claim 16 wherein the step 
of representing relations between said network 
entities includes defining connections between 
network devices by connection relations between 
models . 

20. A method as defined in claim 16 wherein the step 
of representing relations between said network 
entities includes representing hierarchical 
relations between network entities by hierarchical 
relations between models. 

21. A method as defined in claim 16 wherein the step 
of processing the data is triggered by a change in 
specified data in the same model. 
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22. A method as defined in claim 16 wherein the step 
of processing the data is triggered by a change in 
specified data in a different model. 

23. A method as defined in claim 15 wherein the step 
of processing the data includes means for generating 
an alarm condition when specified data exceeds 
predetermined limits . 

24. A method as defined in claim 16 wherein said 
means for processing network data includes means for 
generating an event condition when specified data 
m'eets a predetermined criteria. 

25. A method as defined in claim 16 wherein the step 
of representing network entities includes 
representing network devices by device models. 

26. A method as defined in claim 16 wherein the step 
of representing network entities includes 
representing geographical locations of network 
devices by geographical models. 

27. A method as defined in claim 16 wherein the step 
of representing network entities includes 
representing topological groupings of network 
devices by topological models. 

28. A method for monitoring the status of a network 
comprising a plurality of interrelated network 
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entities, said method comprising the steps of: 

maintaining in a computer system a 
representation of the network including models and 
relations between models, each model corresponding 
to one or more of the network entities and including 
status information regarding one or more network 
entities, each model further including one or more 
inference handlers; 

said representation of the network communicating 
with selected ones of the network entities and 
obtaining operational information; 

said inference handlers updating the status 
information in said models in response to said 
operational information; and 

said representation of the network providing the 
status information to a user. 

29. A method as defined in claim 28 wherein said 
inference handlers update the status information in 
said models in response to said operational 
information and in response to information obtained 
from other models. 

30. A method for isolating a network fault using a 
network management system, comprising the steps of: 

when contact between the network management 
system and a first network device is lost, setting a 
fault status for the first network device; 

determining the fault status of all network 
devices adjacent to the first network device; 
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when the fault status of each network device 
adjacent to the first network device is set, 
suppressing the fault status of the first network 
device; and 

when the fault status of at least one network 
device adjacent to the first network device is not 
set, maintaining the fault status of the first 
network device. 

31. A method as defined in claim 30 wherein said 
network management system includes models of network 
entities and model relations between network 
entities, the fault status of each network entity 
being contained in the corresponding model and 
wherein the fault status of each network entity is 
obtained by regularly polling the corresponding 
network device . 

32. A method as defined in claim 31 wherein the step 
of determining the fault status of all network 
devices adjacent to the first network device 
includes a model of the first network device 
watching the fault status in models of all network 
devices adjacent to the first network device. 

33. A method as defined in claim 32 wherein said 
models and model relations represent hierarchical 
relations between network devices and wherein, when 
fault status of all network devices at a given level 
of the hierarchy is suppressed, the fault status is 



BNSDOCID; <WO 9205485A2_I_> 



wo 92/05485 



PCr/US91/06725 



- 45 - 

set in a model of the next higher level of the 
hierarchy. 

34. A method for isolating a network fault, 
comprising the steps of: 

when commxinication with a first network element 
is lost, setting a fault status for the first 
network element; 

determining the fault status of all network 
elements adjacent to the first network element; 

when the fault status of each network elements 
adjacent to the first network element is set, 
suppressing the fault status of the first network 
element; and 

when fault status of at least one of the network 
elements adjacent to the first network element is 
not set, identifying the first network element as 
the source of the network fault. 

35, A method for isolating a network fault using a 
network management system, comprising the steps of: 

when contact between the network management 
system and a first n twork device is lost, setting a 
fault status for the first network device; 

determining whether the network management 
system is able to contact all network devices 
adjacent to the fir sr. r.etwork device; 

when the network management system is unable to 
contact all network devices adjacent to the first 
network device, suppressing the fault status of the 
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first network device; and 

when the network management system is able to 
contact at least one network device adjacent to the 
first network device, maintaining the fault status 
of the first network device. 

36. A method for displaying information relating to 
a computer network to a user, comprising the steps 
of: 

maintaining information relating to a computer 
network in a network management system; 

in response to user selections, said network 
management system providing a first set of views 
showing information relating to said computer 
network, said first set of views having a 
hierarchical relationship; 

in response to user selections, said network 
management system providing a second set of views 
showing information relating to said computer 
network, said second set of views having a 
hierarchical relationship; and 

in response to user selections, said network 
management system traversing between said first set 
of views and said second set of views . 

37. A method as defined in claim 36 wherein said 
first set of views comprise topological views 
showing interconnections between network entities in 
said computer network. 
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38. A method as defined in claim 37 wherein said 
second set of views comprise location views showing 
locations of network entities in said computer 
network. 

39. A method as defined in claim 36 wherein said 
first set of views and said second set of views 
include icons representative of network entities. 

40. A method as defined in claim 38 wherein said 
topological views and said location views include - 
icons representative of network entities. 

41. A method as defined in cl -im 36 further 
including the step of said network management system 
providing visual displays of detailed information 
relating to said network and, in response to user 
selections, traversing between said visual displays, 
said first set of views and said second set of 
views . 

42. A method as defined in claim 36 further 
including the step of said network management system 
updating the information to reflect a substantially 
current state of said computer network. 

43. A method as defined in claim 39 wherein the step 
of maintaining information includes said network 
management system having models of said network 
entities, said models containing information 
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relating to corresponding network entities and 
providing said information to said first set of 
views and said second set of views. 

44. A method as defined in claim 43 wherein each 
icon has a corresponding model in said network 
management system. 

45. A system for displaying information relating to 
a computer network, comprising: 

a digital computer, a video display unit 
connected to the computer and storage means 
connected to the computer; 

means for maintaining and updating information 
relating to a computer network in the storage means; 

means for generating on said video display unit 
a first set of user selectable views showing 
information relating to said computer network, said 
first set of views having a hierarchical 
relationship; 

means for generating on said video display unit 
a second set of user selectable views showing 
information relating to said computer network, said 
second set of views having a hierarchical 
relationship; and 

means for traversing between said first set of 
views and said, second set of views in response to 
user selections . 

46. A system as defined in claim 45 wherein said 
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first set of views comprises topological views 
showing interconnections between network entities in 
said computer network. 

47. A system as defined in claim 46 wherein said 
second set of views comprises location views showing 
locations of network entities in said computer 
network. 

48. A system as defined in claim 45 wherein said 
means for generating a first set of views and said 
means for generating a second set of views each 
include means for generating icons representative of 
network entities. 

49. A system as defined in claim 45 wherein said . 
means for maintaining and updating information 
includes means for updating the information to 
refle t a substantially current state of said 
computer network. 

50. A method for displaying information relating to 
a computer network to a user, comprising the steps 
of: 

maintaining information relating to network 
entities of a computer network in a network 

management system; 

said network management system providing a 
visual display of the information relating to the 
network entities, said network entities being 
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represented on said visual display by icons, each 
having a plurality of user selectable areas; and 

in response to a user selection of a prescribed 
area of an icon, said network management system 
providing a visual display of detailed information 
regarding a predetermined aspect of the network 
entity which the icon represents, each user 
selectable area of said icon providing access to a 
different visual display of detailed information 
regarding said network entity. 

51. A method as defined in claim 50 wherein said 
icon includes a first area that represents a first 
parameter of the corresponding network entity and 
wiierein said network management system provides 
detailed information regarding the first parameter 
of the corresponding network entity when the user 
selects the first area of the icon. 

52. A method as defined in claim 51 wherein said 
icon includes a second area that represents a second 
parameter of the corresponding network entity and 
wherein said network management system provides 
detailed information regarding the second parameter 
of the corresponding network entity when the user 
selects the second area of the icon. 

53. A method as defined in claim 5-2 wherein said 
icon includes a third area that contains type 
information regarding the network entity and wherein 
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the network management system provides detailed 
configuration information regarding the 
corresponding network entity when the user selects 
the third area of the icon. 

54. A method as defined in claim 53 wherein said 
icon includes a fourth area and wherein the network 
management system provides a pictorial 
representation of the corresponding network entity 
when the user selects the fourth area of the icon. 

55. A method as defined in claim 52 wherein said 
first parameter comprises the status of the 
corresponding network entity and said second 
parameter comprises the performance of the 
corresponding network entity. 

56. A method for displaying information relating to 
a computer network to a user, comprising the steps 
of: 

monitoring network entities of a computer 
network with a network management system and 
generating alarms when predefined events occur in 
said network entities; 

said network management system providing a 
visual display of said alarms; 

in response to a user selection of one of said 
alarms, said network management system displaying an 
icon representative of the network entity having an 
alarm, said icon having a plurality of user 
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selectable areas ; and ' 

in response to user selection of a prescribed 
area of the icon, said network management system 
providing a visual display of detailed information 
regarding a predetermined aspect of the network 
entity which the icon represents. 

57. A method as defined in claim 56 wherein said 
network management system displays said icon as part 
of the visual display of said alarms. 

58. A method as defined in claim 57 further 
including the step of said network management system 
displaying text information relating to the user 
selected alarm. 

59. A method as defined in claim 56 wherein said 
icon includes a first area that represents a first 
parameter of the corresponding network entity and 
wherein said network management system provides 
detailed information regarding the first parameter 
of the corresponding network entity when the user 
selects the first area of the icon. 

60. A method as defined in claim 59 wherein said 
icon includes a second area that represents a second 
parameter of the corresponding network entity and 
wherein said network management system provides 
detailed information regarding the second parameter 
of the corresponding network entity when the user 
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selects the second area of the icon. 

61. A method as defined in claim 59 wherein said 
icon includes a third area that contains type 
information regarding the network entity and wherein 
the network management system provides detailed 
configuration information regarding the 
corresponding network entity when the user selects 
the third area of the icon. 

62. A method as defined in claim 60 wherein said 
icon includes a fourth area and wherein the network 
management system provides a pictorial 
representation of the corresponding network entity 
when the user selects the fourth area of the icon. 

63. A method as defined in claim 60 wherein said 
first parameter comprises the status of the 
corresponding network entity and said second 
parameter comprises the performance of the 
corresponding network entity. 

64. A system for displaying information relating to 
a computer network, comprising: 

a digital computer, a video display unit 
connected to said computer and storage means 
connected to said computer; 

means for maintaining and updating information 
relating to network entities of a computer network 
in said storage means; 
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means for displayirig on said video display unit 
information relating to said network entities, 
including means for representing said network 
entities on said video display unit by icons, each 
icon having a plurality of user selectable areas; and 

means for providing on said video display unit a 
display of detailed information regarding a 
predetermined aspect of the network entity which the 
icon represents in response to a user selection of a 
prescribed area of the icon, each user selectable 
area of said icon providing access to a different 
display of detailed information regarding said 
network entity. 

65. A system for displaying information relating to 
a computer network, comprising: 

a digitial computer, a visual display unit 
connected to said computer and storage means 
connected to said computer; 

means for monitoring network entities of a 
computer network and for generating alarms when 
predefined events occur in said network entities; 

means for providing a display of said alarms on 
said video display unit; 

means for displaying on said video display unit 
an icon representative of a network entity having an 
alarm in response to a user selection of one of said 
alarms, said icon having a plurality of user 
selectable areas; and 

means for providing on said video display unit a 
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display of detailed information regarding a 
predetermined aspect of the network entity which the 
icon represents in response to a user selection of a 
prescribed area of the icon. 
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A network management system includes a user interface, a 
virtual network and a device communication manager. The virtu- 
al network includes models which represent network entities and 
model relations which represent relations between network enti- 
ties. Each model includes network data relating to a correspond- 
ing network entity and one or more inference handlers for pro- 
cessing the network data to provide user information. The system 
performs a fault isolation technique wherein the fault status of a 
network device is suppressed when it is determined that the de- 
vice is not defective. User displays include hierarchical location 
views and topological views of the network configuration. Ne- 
twork devices are represented on the displays by multifunction 
icons which permit the user to select additional displays showing 
detailed information regarding different aspects of the corre- 
sponding network device. 
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